David Berlind: “Perhaps the best solution I’ve seen that does roughly the same thing and that makes synchronization between the local and network-based storage (and just requires a low-overhead local HTTP server) is Userland’s Radio blogging solution (credit to Dave Winer). More and more, solution providers will recognize the genius in that design as they look to deal with the offline problem as elegantly as possible given today’s constraints.”
Google platform getting offline support?
The following phrase jumped out at me from a post Rafe Needleman made earlier today about Google Docs & Spreadsheets:
Google is going to “take a shot” at a disconnected version, for users who want to access files when they are offline.
While I was digging around trying to figure out where he got this, Garett Rogers posted his own discovery:
As you probably know, I really like to dig through source code — and sometimes I find things. […] I will start with the most interesting piece of code I found. Google is working on a solution that will allow you to install Writely on your local machine:
if (location.host.indexOf("localhost") > -1) { if (location.host.indexOf("Prefactor") > -1) return "http://localhost:8180/Prefactor/" + page + paramString; else return "http://localhost:8180/Docster/" + page + paramString; } else return "http://" + location.host + "/" + page + paramString;
This is absolutely huge news. Regular readers of my blog know that I view Google’s lack of an offline story (in all but a few areas anyway) as its biggest hole, particularly when stacked against Microsoft, where that’s arguably its greatest strength. So, the fact that Google is working on this is big news is itself.
I’m also intrigued by the method they’re apparently using, namely a localhost web server, rather than a thick client or persistent storage via a browser extension. I’ve been thinking for a long time about the offline problem, and I’ve come to the conclusion that localhost web servers (which I first saw used to great effect in Radio Userland—credit where credit is due) are the ideal solution.
Thick clients play to Microsoft’s strength (not to mention the OS issue), so that’s not the best approach. And the notion of adding persistent storage to the browser opens up a host of cross browser compatibility problems. And while it may be possible to come up with a standard API that works across Firefox, IE, and other browsers, such a standard is likely years away, particularly given that we haven’t even begun the “competing implementations battle it out” phase yet.
Mike Melanson: “What could possibly be so difficult about porting the Flash Player to Linux? I’m glad you asked…”
Steven Vaughan-Nichols: “Given a choice between the Firefox they already know about and ‘IceWeasel,’ [users are] going to go for Firefox. Or, maybe, just maybe, instead of dealing with this confusing Linux stuff, they’ll stick with Windows after all.”
Steven is right on the money with this rant. This is so maddeningly stupid I’m embarrassed to be even remotely associated with this.
Google Reader gets it right
Google Reader relaunched a few weeks ago, and for the first time since my initial foray into blogging with Radio Userland in 2003, I’m actually enjoying using an RSS reader.
Why? River of news. Most feed readers inexplicably model the email workflow, presenting feeds like folders and feed items like messages. Given the state of most peoples’ inboxes, why on earth would you model email when you’re writing one of these things?
Google Reader does river of news right. Simply click on “All items” and scroll through the items with the mouse wheel, clicking on the interesting stories (or reading them inline when the feed is full text). Google Reader takes care of marking the items read as they scroll past. Automatically.
The praise doesn’t stop there. There are handy keyboard shortcuts (“n” for next item, “r” to refresh, etc.). Performance is excellent, as feed items are loaded on demand using AJAXy techniques. The look and feel is clean and simple, reminiscent of Gmail, down to easy to read timestamps like “9:53 AM (7 minutes ago)”; and, also like Gmail, there’s a mobile version.
Intriguingly, you can sort by “auto” in addition to by newest, which presumably applies some sort of relevance algorithm to the feed items. However, it isn’t clear how it determines relevance (does it track my clicks as I scroll through the feeds, examine my broader search history, what?).
Google Reader is a good platform citizen too. There’s a gadget you can add to your personalized Google home page, and gadgets, in case you missed it, are becoming full fledged web components as of last week. Oh, there’s an API too.
Finally, in concert with Mozilla Firefox 2, subscribing to feeds finally no longer involves configuring a bookmarklet or, worse, the complex gymnastics of right click/copy link location/go to the appropriate URL/paste/subscribe. With Firefox 2, you can configure the feed subscriber to use Google Reader. As a result, you can now click on the feed icon in the address bar to subscribe to the site’s feed. In most cases, you can even click on a link to an RSS/Atom feed, for those sites that don’t have autodiscovery configured properly. My only complaint here is that it doesn’t remember that I want to subscribe in Google Reader; rather, it asks whether I want to “Add to Google Homepage” or “Add to Google Reader” every time. Ideally, it would show me a preview of the feed instead. I’ve seen Google Reader do that before, so perhaps it’s just a matter of configuring it to go to a different URL, though I’m not sure how to do that.
So, what’s not to like here? As with most Google products, it’s not particularly well integrated with the Google platform. Indeed, in that particular post, I complained that there were three different ways of creating a bookmark in the Google platform. Well, there now appear to be four. If all of these mechanisms were integrated, that would be enormously powerful. See something interesting in the Google Reader? Click on the star and, optionally, add tags. See something interesting on the search results page? Ditto. See something interesting on a random webpage? Pull down a menu on the Google Toolbar and do the same thing that way. Want to add free form notes to any of the above bookmarks? Pop into Google Notebook. Naturally, all of these actions should result in the bookmarks/tags/notes/etc. being added to a single stream that can be shared with other users, with all of the resulting social network functionality. Etc. etc. etc.
Sigh. I guess I have to be patient a little bit longer. Fortunately, Google sees the problem and is finally doing something about it.
Pot. Kettle. Black.
Steven Vaughan-Nichols: “The Debian community sees Mozilla as being unreasonable about its trademarks. I find that more than a little curious, since Debian has long been just as protective and possessive of its own Debian name and logo. For example, the DCC Alliance, which is made up of nothing but Debian companies and was led by the founder of Debian, was forced to drop Debian from its name because of the Debian community’s hostility.”
Gawd.
Features, not products
Los Angeles Times: “[Google’s] top executives said Thursday that they had begun telling engineers to stop launching so many new services and instead focus on making existing ones work together better.”
Dunc Tank, Debian, and leadership
I’ve been asked by numerous people for my take on Dunc Tank, the latest “conspiracy” to roil the Debian waters. (Summary: Dunc Tank aims to raise funds to pay Debian developers to complete certain key projects, such as ensuring the next version of Debian, etch, is released on time.)
My take is simple: The kind of childish sniping that has taken place over the past few weeks (which, as usual, seems to come from a small but extremely vocal corner of the community) does far more harm to Debian than any perceived monetary “taint”. It’s no wonder “the enterprise” doesn’t take Debian seriously.
If anything, I’m encouraged by what I’ve seen lately, namely that Debian finally has strong leadership that’s willing to take necessary steps without fear of offending the mob of the few that often paralyzes these kinds of projects.
Bravo, AJ. And keep at it. It takes a steely sort of person to stick their necks out like this, but strong leadership is absolutely essential to the success of any project, open source or otherwise. After all, success doesn’t just happen at random.
What’s new with the LSB
It’s been a while since I’ve written about the LSB here, so I figured I was overdue to give an update. In short, it’s been a great year. Highlights include:
» All major distributions, including Asianux, Debian, Mandriva, Red Hat, SUSE, and Ubuntu, are either already certified to LSB 3, in the process of certifying, or planning to certify their next version (see our list of expected distribution coverage for LSB 3).
» A number of ISVs (independent software vendors), including MySQL and RealNetworks, are in the process of certifying applications to LSB 3. For ISVs, LSB certification means fewer distribution specific packages without sacrificing distribution coverage (take a look at the MySQL download page for an example of how crazy it can get). For users, LSB certification means greater application availability with a minimum of hoops to jump through. Expect a lot more announcements about LSB certified applications in the coming months.
» We’ve put together a solid roadmap for the LSB going forward. The LSB aims to provide a “highest common denominator” across the various Linux distributions—in other words, to provide a single target for ISVs writing or porting to the Linux platform, where “the Linux platform” is defined by a short (and potentially different from ISV to ISV) list of distributions on which their applications must run.
To serve as an effective highest common denominator, it needs to be easy to map from LSB versions to distributions and vice versa; and it needs to be possible to target a version of the LSB with assurance that the application will work not only on that version but on future versions as well (i.e., an LSB 3.0 application will run on LSB 3.0, 3.1, 3.2, 4.0, … compliant distributions). We’ve made great strides toward these goals in the past few months.
To satisfy the “easy mapping” requirement, each major version of the LSB now corresponds to a major version, or “generation”, of the enterprise distributions. So, for example, LSB 3.x corresponds to the current generation (Red Hat Enterprise Linux 5, SUSE Linux Enterprise 10, etc.), LSB 4.x corresponds to the next generation (RHEL 6, SLE 11, etc.), etc. To satisfy the application compatibility requirement, LSB versions both major and minor beginning with 3.0 are strictly backward compatible with previous versions.
At a high level, then, the LSB roadmap looks something like this:
| LSB 3.x (2006-2008) | LSB 4.x (2008-2010) |
|---|---|
|
Asianux 2.0 Debian 4.0 (“etch”) Mandriva Corporate 4.0 Red Hat Enterprise Linux 4 & 5 SUSE Linux Enterprise 9 & 10 Ubuntu 6.06 LTS (“dapper”) […] |
Asianux 3.0 Debian “etch” + 1 Mandriva Corporate 5.0 Red Hat Enterprise Linux 6 SUSE Linux Enterprise 11 Ubuntu LTS “dapper” + 1 […] |
» Speaking of the LSB roadmap, we’re hard at work on LSB 3.2, to be released Q2 2007. The short list of new features include the addition of Perl, Python, several freedesktop.org specifications for desktop interoperability, CUPS, HPIJS, ALSA, and more. For LSB 4.0, we’ll be uplifting LSB Core to GCC 4.1 and glibc 2.4 and looking at two longstanding issues, the addition of Java and a packaging facility for ISVs, among many other things. The roadmap will be posted for public comment shortly.
» We’re making it easier than ever to build portable applications using the LSB. We released the LSB SDK (Software Development Kit), which bundles everything a developer needs to write or port to the LSB, with LSB 3.1. We’re building something called the LSB Application Testkit, which aims to be the LSB’s validator.w3.org, an easy to use tool that developers can use to test for application portability. And we quietly launched a beta version of the LSB Developer Network last month.
» In July, we hired Till Kamppeter, making linuxprinting.org, the de facto standard repository of Linux printer drivers, an FSG project. We’re adding both distribution neutral printer drivers (delivered, naturally, as LSB packages) to the linuxprinting.org foomatic database as well as an API that third party printer management tools can use to install and update printer drivers. We also plan to extend the LSB certification program to cover printers in addition to distributions and applications. If all goes well, you’ll be able to look for the LSB Certified mark on a printer at the store and know that it will work on your distribution of choice in the not too distant future.
» Last, but certainly not least, we’re embarking on an exciting new project in partnership with the Institute for Systems Programming at the Russian Academy of Sciences to build the next generation LSB database and test suite infrastructure. The new system will interlink the various moving parts that make up the Linux platform to an unprecedented degree, providing upstream developers and distribution vendors a powerful set of tools for coordinating their work and improving the quality of the platform, as well as giving ISVs a more efficient way to provide feedback to both parties. This is a key tool for enabling the backward compatibility guarantee mentioned earlier, and it will also vastly improve the coverage and quality of the LSB tests, an area where we’ve been criticized in the past (our goal is 75% interface coverage by LSB 4.0). More details here.
I’ll drill down on all of these topics and more in the coming months. In the meantime, you can keep up with the latest at the FSG and LSB by visiting the FSG web site or by signing up for the FSG newsletter (sorry, no RSS feed yet, though I’m told we’re working on it). Finally, if you’re interested in participating in the LSB project, join the lsb-discuss mailing list or the IRC channel #lsb on irc.freestandards.org, where the bulk of LSB development happens.